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Abstract 



Administrative role-based access control (ARB AC) is the first comprehensive administra- 
tive model proposed for role-based access control (RBAC). ARBAC has several features for 
designing highly expressive policies, but current work has not highlighted the utility of these 
expressive policies. In this report, we present a case study of designing an ARBAC policy for 
a bank comprising 18 branches. Using this case study we provide an assessment about the 
features of ARBAC that are likely to be used in realistic policies. 

1 Introduction 

This case study describes the design of an administrative role-based access-control (ARBAC) pol- 
icy for a bank comprising 18 branches. We designed the ARBAC policy to meet the following two 
goals: 

1. Facilitate the business functions in each branch by appropriately provisioning roles to facil- 
itate the tasks of each job position. 

2. Enforce a separation of privilege (SOP) property to prevent collusive behavior in the execu- 
tion of important job tasks. 

The business functions and job roles used in each bank branch are based on an existing study. 
Schadd et al. |3| describes a role-based access-control (RBAC) policy for an European bank branch. 
We extend this policy into an ARBAC policy in two steps. First, we add 17 additional branches 
with the same functions and job roles. This is because we limited our case study to 18 branches, 
which is approximately 600 roles based on the number of roles in each branch. Second, we de- 
signed canjjssign and can_revoke rules for administering role assignment actions such that the SOP 
property is enforced. 

SOP is a key concern for financial institutions because they are required to enforce such prop- 
erties either by regulators or to be compliant with standards such as ISO 9000 |2|. SOP has its 
primary objective in the prevention of fraud or collusive behavior in crucial operations. Typically, 
SOP is enforced by dividing tasks and privileges for executing an operation among multiple users, 
and making sure that a single user cannot obtain all the privileges necessary for independently 
completing an operation. 
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For example, let us consider that the Widget corporation wants to enforce a high level of trans- 
parency in the processing of purchase orders. To meet this objective. Widget splits the purchase 
order transaction into two tasks, namely creation and approval. The permissions for the tasks are 
assigned such that junior level employees have the ability to create purchase orders, but only the 
division's manager can approve the purchase orders. Formally, the SOP constraint for this exam- 
ple can be stated as, ( { Creation, Approval}, 1 ), which means that a user can at most have one 
role from the set { Creation, Approval}. 

This case study illustrates how SOP constraints can be enforced by using a well designed 
ARBAC policy. Three features of ARBAC, namely disjunctions, positive preconditions, and mixed 
roles, are useful in expressing the SOP constraints. This case study illustrates how these features 
are used in the policy. These features are complexity sources with respect to analyzing these 
policies for safety. Therefore, use of these features makes the automatic analysis of ARBAC policies 
harder. However, because of the utility of these features in enforcing properties such as SOP, we 
envision that realistic policies will take advantage of these features. 

This case study also describes how to formulate safety queries for verifying properties of the 
policy. Formally, a safety query is a tuple of the form {u, r ) that questions whether a user u can 
be assigned to a role r. Several questions about the policy can be formulated as one or more safety 
queries |jlj(4|. We illustrate this with examples of safety queries for verifying the SOP property. 
Model checkers could be used for verifying these safety questions prior to deploying the policy. 

The remainder of this case study is structured as follows. Section |2] describes the roles and the 
role hierarchy in the policy. Section |3] describes the design of the canjissign and can_revoke rules. 
Section |4] describes how to formulate analysis questions. Section |5] provides a summary. 



2 Roles and Role Hierarchy 

The bank comprises 18 branches. Each branch in the bank has 33 roles that are spread over four 
business divisions, namely financial analyst (FA), share technician (ST), office banking (OB), and 
support e-commerce (SE). Table [T] contains the list of roles in each branch and Figure [l] contains 
the role hierarchy. There are eight roles per business division, comprising the following: 

1. A role for each business division from which all the other roles in the business division 
inherit. For example, all the roles in the FA business division inherit from the FA role. 

2. Two managerial roles. For example, FA-HOD and FA-GM are managerial roles in the FA 
division. 

3. Five non-managerial roles. For example, FA-Asst, FA-Specialist, FA-Senior, FA-Junior, and 
FA-Clerk are non-managerial positions in the FA division. 

Each branch has a role called employee, from which all other branch-specific roles inherit. Each 
branch has the same set of roles, leading to 594 roles in the bank policy comprising 18 branches. 

In each branch, the five non-managerial roles in each business division have a separation of 
privilege constraint such that a user may not be assigned to more than 3 roles of the five roles. For 
example, FA-Asst, FA-Specialist, FA-Senior, FA-Junior, and FA Clerk are the five junior roles in the 
FA division. A user who is already assigned to one of these roles can be additionally assigned to 
at most 2 roles out of the remainder four roles. 

Our policy assumes separate administration, which implies that administrative roles are not 
managed by the same set of rules that apply to the regular roles. We have a single role named Ad- 
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Table 1: Roles Derived from Function and Official Positions 
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Figure 1: Role Hierarchy Design 



min used for administering role assignments and revocations. Therefore, the Admin role appears 
as a precondition in all the assignment and revocation rules. 

3 Can^ssign and Can Revoke Rules 

We designed can_assign rules to enforce the constraint that a user can be assigned to at most 3 
roles out of the five non-managerial roles in each business division. This constraint can be stated 
formally as. 



The canjissign rules are designed to express the valid conditions for assigning a user to a par- 
ticular role. The conditions specify the role memberships that are required for user to be assigned 
to a role. To meet our SOP objective, we need to enumerate all the valid conditions that can en- 
title a user to be assigned to each of the five non-managerial role. These conditions can then be 
expressed as one or more canjissign rules. 

We illustrate the design of the canjissign rules using an example. For example, let us consider 
the FA-Clerk role. Table |2]contains the canjissign rules for the role FA-Clerk. A user can be assigned 
to the role FA-Clerk, under three cases: 

1. Case 1: If a user is is not assigned to any other managerial role, then he can be assigned to 
the FA-Clerk role. To express this condition, we created a canjissign rule that contains FA as 
a positive precondition and four negative preconditions for the other four non-managerial 
roles. 

2. Case 2: If a user is already assigned to a single non-managerial role, then the user may 
be assigned to an additional non-managerial role. To express this condition, we need four 
canjissign rules. Each of these four rules will have 2 positive preconditions and 3 negative 



( {FA-Asst, FA-Specialist, FA-Senior, FA-Junior, FA Clerk}, 3 ) 
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Table 2: Can_Assign rules for FA-Clerk Roles 



preconditions. Of the two positive preconditions, one is for a business division role FA 
and the other is one of the four non-managerial roles. The remainder non-managerial roles 
appear as negative preconditions. 

3. Case 3; If a user is already assigned to two non-managerial roles, then the user can be as- 
signed to an additional non-managerial role. To express this condition, we need six canjissign 
rules. Each of the six rules have 3 positive preconditions and 2 negative preconditions. The 3 
positive preconditions include the business division role and two of the four non-managerial 
roles. The remainder non-managerial roles appear as negative preconditions. 

As illustrated by Table |2| the canjissign rules make use of disjunctions, positive preconditions, 
and mixed roles. The valid conditions for assigning the FA-Clerk role is essentially a disjunc- 
tion, in which each canjissign rule is a disjunct. Also, several of the canjissign rules have mixed 
preconditions because they have both positive and negative preconditions. 

We followed the same procedure for designing the canjissign rules for all the other non-managerial 
roles. The complete list of the canjissign and canjrevoke rules can be obtained from our policy filqj 

The can_assign rules for the managerial roles were designed to enforce that a user assigned to 
any of the non-managerial roles cannot be assigned to a managerial role. Therefore, assignment 
rules for the managerial roles had negative preconditions for all the non-managerial roles and one 
positive precondition for the business division role. 

In our policy, all the roles are revocable. Therefore, we had 594 can_revoke rules, one for each 
role. We did not see any reason to make a branch-specific role irrevocable. 

4 Analysis Questions 

As mentioned earlier, several questions about the policy can be expressed as a safety query. We 
illustrate how the following two analysis questions can be expressed as a safety query: 

1. Can a user be assigned to four non-managerial roles in a business division in any of the 18 
branches? 

2. Can a user be assigned to four non-managerial roles in a business division in all the 18 
branches? 

^ http : / /k jayaram.mysite . syr . edu/mohawk /Mohawk . html 
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Both these questions can be encoded as a safety question of the form {u, targetrole) as follows. 

To express these analysis questions as safety queries, we need to add some additional roles, 
canjissign, and can. revoke roles. These additions do not affect the valid administrative actions for 
the other roles described in the policy. 

For each branch, we add two additional roles, i.e., we add roles AnyFouVi and Branchi for each 
branch. The objective of the AnyFoufi is to identify if a user can be assigned to four non-managerial 
roles. We add canjissign rules for this role in each branch to express the condition that if a user is 
a member of four non-managerial roles, then he may be assigned to this special role. The Branchi 
roles help in the encoding of both safety questions, so we will refer to them as helper roles. The 
canjissign rules for each of the helper roles express the condition that if a user can be assigned to 
either AnyFouti or Branch (^^^i^^, then he may be assigned to Branchi. 

To express question (1) as a safety question, we add a single canjissign rule for targetrole that 
is of the form [Admin, branchi, targetrole). The consequence of this rule is that If a user can be 
assigned to targetrole, then it implies that a user can be assigned to four non-managerial roles in 
at least one of the 18 branches. 

To express question (2) as a safety question, we add a single canjissign rule for targetrole that is 
of the form (Admin, branchi A .. A brancig, targetrole). The consequence of this rule is that if a use 
can be assigned to targetrole, then it implies that a user can be assigned to four non-managerial 
roles in all the branches. 

5 Summary 

We illustrated the design of an ARB AC policy with the intent of enforcing separation of privilege 
for a bank comprising 18 branches. The separation of privilege constraint that we have used is 
emblematic of realistic concerns. Disjunctions, positive preconditions, and mixed roles are very 
useful for encoding SOP constraints. The SOP constraints can be verified by designing safety 
queries. 
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